Improving Offline Map Data Availability

ABSTRACT

To provide geographic data to client devices for offline use, a system receives, from a client device via a communication network, an indication of a current location of the client device. The system identifies geographic data to be provided to the client device to define an area of offline coverage, which includes determining boundaries of the area of offline coverage based on an amount of geographic data the client device is expected to receive prior to reaching certain points within the area of offline coverage. The system provides the geographic data to the client device.

CROSS-REFERENCE TO RELATED TO APPLICATIONS

This application is a divisional of U.S. application Ser. No.16/603,548, filed on Oct. 7, 2019, which is a national stageapplication, filed under 35 U.S.C. § 371, of International ApplicationNo. PCT/US2018/54617, filed Oct. 5, 2018, the disclosures of which areincorporated by reference herein in their entireties.

FIELD OF THE DISCLOSURE

The present disclosure relates to digital maps and, more particularly,to generating digital maps that include information of interestspecifically to the user viewing the digital map.

BACKGROUND

Today, numerous electronic devices such as personal computers, tablets,mobile phones, navigators provided as special-purpose devices orembedded into head units of vehicles, etc. can provide digital maps ofgeographic areas as well as step-by-step directions for navigatingthrough geographic areas by driving, walking, bicycling, or using publictransport. Special-purpose mapping applications or “apps” as well asgeneral-purpose applications such as web browsers can provide digitalmaps and/or navigation directions.

Many geographic systems today retrieve geographic data, such as map datato render digital maps or point-of-interest data to service geographicsearch queries, from network servers. These geographic systems retrievedata as needed and no longer rely on permanent pre-stored databases.However, these systems often encounter problems with connectivity orinsufficient bandwidth and, as a result, a device at a certain locationsometimes cannot generate a digital map or service a geographic query.

SUMMARY

A client device of this disclosure retrieves geographic data forgeographic areas of offline coverage prior to reaching locations inthese geographic areas, from a server via a wireless communicationnetwork. An offline management system determines the extent of the areaof offline coverage as well as when the client device should requestadditional geographic data. The area of offline coverage is based onpredicted destinations to which the client device is likely to travel aswell as a padding region for these predicted destinations. The offlinemanagement system can determine the extent of the area of offlinecoverage in view of the quality of network coverage, e.g., usingestimated bandwidth for various service providers at the various regionsand the speed at which the client device is expected to move throughthese regions. The management system thereby reduces the probabilitythat the client device neither can retrieve the relevant geographic areafrom the server nor has the relevant geographic area pre-stored in itsmemory.

When determining the extent of the area of offline coverage, the offlinemanagement system can use the navigation route along which the clientdevice current is moving or, when no navigation route has beenrequested, likely destinations to which client devices generally tend totravel from the current location of the client device. More generally,the offline management system can use any suitable combination ofnon-personal signals (e.g., popularity of locations, historical data,availability and size of roads leading to the locations) as well aspersonal signals (e.g., locations previously visited by the useroperating the client device or locations “liked” by the user, when theuser has indicated, by operating certain controls or installing certainapplications, that the offline management system can use the personalsignals to retrieve geographic data).

To determine the padding region, the offline management system in anexample implementation calculates the amount of data the client deviceis expected receive at various geographic locations, which can be mappedto cells of a certain fixed size (at least upon transformation orprojection) to make computation finite, and determines various locationsthe client device can reach for a given “budget” expressed as a numberof megabytes of data, for example. The offline management system thendetermines the amount of data required to cover the region made up ofthese locations reachable for the given budget, and adjusts the budgetas needed. The offline management system then repeats these calculationsuntil the values representing the amount of data required to cover theregion and the budget converge.

Further, to service client devices in real time more efficiently, theserver-side component of the offline management system can pre-calculategeographic data that covers likely destinations for geographic locationsas well as padding regions for various locations.

One example embodiment of these techniques is a method for obtaininggeographic data for offline use. The method includes storing, in amemory of a computing device, geographic data corresponding to a certaingeographic area of offline coverage; obtaining, by one or moreprocessors, an indication of a geographic boundary delimiting a regionsmaller than, and contained within, the geographic area; determining, bythe one or more processors, a current location of the computing devicerelative to the geographic boundary; in response to determining that thecurrent location is outside the region, retrieving additional geographicdata via a wireless communication network to expand the geographic areaof offline coverage; and providing at least some of the geographic datacorresponding to the expanded geographic area when the computing deviceis offline.

In various implementations, this method includes one or more of thefollowing additional features. Retrieving the additional geographic dataincludes transmitting, to a network server, a request specifying thecurrent location of the computing device and an indication of thegeographic area of offline coverage. The request further specifies anetwork carrier of the computing device at the current location. Therequest further specifies a navigation route which the computing deviceis following. The request further specifies a current speed and/or anexpected future speed of travel of the computing device. Retrieving theadditional geographic data includes receiving, from a network server,geographic data for locations to which the computing device is likely totravel. Requesting the additional geographic data includes requestingmap data for rendering digital maps.

Another example embodiment of these techniques is a computing devicecomprising one or more processors and a non-transitory computer-readablememory that stores instructions. When executed by the one or moreprocessors, the instructions cause the computing device to implement anyof the methods above.

Yet another example embodiment of these techniques is a method forproviding geographic data to client devices for offline use. The methodincludes receiving, by one or more processors from a client device via acommunication network, an indication of a current location of the clientdevice; identifying, by the one or more processors, geographic data tobe provided to the client device to define an area of offline coverage,including determining boundaries of the area of offline coverage basedon an amount of geographic data the client device is expected to receiveprior to reaching certain points within the area of offline coverage;and providing the geographic data to the client device.

In various implementations, this method includes one or more of thefollowing additional features. Determining the boundaries of the area ofoffline coverage comprises determining, within the area of offlinecoverage, a region smaller than the area of offline coverage andcontained within the area of offline coverage, such that the clientdevice is expected to receive the geographic data for the region ofoffline coverage by the time the client reaches any point in the region.The method includes providing an indication of a boundary of the regionto the client device so that the client device requests additionalgeographic data upon reaching the indicated boundary. The methodincludes receiving, from the client device via the communicationnetwork, an indication of a geographic area for which the client devicecurrently stores previously received geographic data. When the methodincludes receiving this indication, the method can include determiningwhether a version of the previously received geographic data is suitablefor use for the region of offline coverage, and not providing thepreviously received geographic data to the client device when theversion of the previously received geographic data is suitable for usefor the region of offline coverage. The method includes determiningnetwork bandwidth for cells within the region based on historical data.

Still another example embodiment of these techniques is a method forproviding geographic data to client devices for offline use. The methodincludes receiving, by one or more processors from a client device via acommunication network, an indication of a current location of the clientdevice; identifying, by the one or more processors, geographic data tobe provided to the client device to define an area of offline coverage,including determining, within the area of offline coverage, a regionsuch that the client device is expected to receive the geographic datafor the region of offline coverage by the time the client reaches anypoint in the region; and providing the geographic data along with anindication of a boundary of the region to the client device so that theclient device requests additional geographic data upon reaching theindicated boundary.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example system in which the offlinemanagement system of this disclosure can operate;

FIG. 2 is a messaging diagram of a scenario in which a client devicerequests geographic data for potential offline use from a geographicdata server;

FIG. 3 is a flow diagram of an example method for obtaining geographicdata from a geographic data server for potential offline use, which canbe implemented in the client device operating in the system of FIG. 1 ;

FIG. 4 is a flow diagram of an example method for removing offlinegeographic data from the local memory, which can be implemented in theclient device operating in the system of FIG. 1 ;

FIG. 5 is a flow diagram of an example method for determining offlinegeographic data and a boundary of a region of sufficient offlinecoverage, which can be implemented in the map data server operating inthe system of FIG. 1 ;

FIG. 6 illustrating example application of S2 cells to a geographicarea;

FIG. 7 illustrates an example relationship between S2 cells and maptiles used to generate digital maps;

FIG. 8 schematically illustrates an example listing of map tilescorresponding to predicted destinations for a certain S2 cell, which theoffline management system of FIG. 1 can use to identify offlinegeographic data to be provided to a client device;

FIG. 9 illustrates an example data structure that stores, for variouscombinations of an S2 cell and a network carrier, an indication ofexpected bandwidth;

FIG. 10 illustrates an example mapping of various combinations of maptile and carrier values to lists of map tiles used in offline padding;

FIG. 11 is a flow diagram of an example method for computing offlinepadding requirements for geographic cells, which can be implemented inthe map data server operating in the system of FIG. 1 ;

FIGS. 12A-C schematically illustrate an example scenario in which aclient device reaches the check-in bounds and requests additionalgeographic data;

FIGS. 13A-E schematically illustrate an example scenario in which thesystem of FIG. 1 determines what geographic data should be provided to aclient device for potential offline use;

FIGS. 14A and 14B schematically illustrate an example scenario in whichthe server of FIG. 1 generates a Mercator covering for a set of S2 cellscorresponding to predicted destinations of the client device;

FIGS. 15A-F schematically illustrate an example scenario in which thesystem of FIG. 1 iteratively determines a padding region for offlinegeographic data; and

FIGS. 16A-C schematically illustrate generating a padding region foroffline geographic data corresponding to a navigation route.

DETAILED DESCRIPTION

An offline management system of this disclosure can be implemented in acomputing environment 100 of FIG. 1 . The offline management system caninclude an offline data controller 102 as well as an offline datamanager 104 defining a server-side component and a client-sidecomponent, respectively. Some of the functionality discussed below canbe implemented in the offline data controller 102, some can beimplemented in the offline data manager 104, and some can be distributedbetween the components 102 and 104.

The example computing environment 100 includes a client device 110, ageographic data server 112, and a communication network 114 which can bea wide area network (WAN) such as the Internet.

The client device 110 in one example implementation operates as acomponent of a vehicle. For example, the client device 110 can be anavigation device embedded in the head unit of the vehicle to providemapping, navigation, search, and other functionality. The client device110 in this implementation can be communicatively coupled to vehiclecomponents 116 which can include various sensors 118 that indicatelocation, orientation, speed, temperature, various operationalparameters of the vehicle such as tire pressure or whether thewindshield wipers have been activated, etc.

In another implementation, the client device 110 is a portable computingdevice such as a smartphone that is communicatively coupled to the headunit of a vehicle via a wired or wireless short-range network interfacesuch as Universal Serial Bus (USB) or Bluetooth®. More generally, theclient device 110 can be any suitable computing device such as a laptopcomputer, a tablet computer, a wearable device, etc.

The client device 110 can include a network interface 120 configured tocommunicate with the map data server 112 and other devices using anysuitable protocols via the network 114. The client device 110 also caninclude a user interface 122 configured to receive typed input,gesture-based input, voice input, etc. and to display images, outputaudio, and generate haptic output for example. The user 122 in anexample implementation includes a touchscreen. Further, the clientdevice 110 can include one or more general-purpose processors 124, anon-transitory computer-readable memory 126, and a graphics card 128(e.g., including one or more graphics processing units, or GPUs). Thememory 126 can include persistent components (e.g., a hard disk) as wellas non-persistent components (e.g., RAM). In other implementations, theclient device 110 may include additional components or, conversely, notinclude some of the components illustrated in FIG. 1 .

The geographic data server 112 can be a network server implemented as asingle device or as a group of devices. One or more of these devices caninclude one or more processors 130 and a non-transitorycomputer-readable memory 132 that stores instructions executable on theone or more processors 130. These instructions can implement, amongother software components, the offline data controller 102 as well as anetwork coverage module 140 and a location predictor 142. Moregenerally, the geographic data server 112 can include any suitable typeof processing hardware that implements the functionality of the modules102, 140, and 142.

With continued reference to FIG. 1 , the geographic data server 112 canbe coupled to a geographic database 150, a network coverage database152, a location history database 154, and a predicted destinations andpadding database 156. Each of the databases 150, 152, 154, and 156 canbe implemented in a single storage device or multiple storage devices.

The geographic database 150 can store map data that includesdescriptions of geometry for various map features such as buildings andother structures, roads, parks, bodies of water, etc. Besides roadsdesigned for vehicles, the map data can describe bicycle paths,pedestrian paths, railway paths, shipping routes, airlines routes, etc.Map features can be defined in a vector graphics format, according towhich images are described in terms of geometrical primitives based onmathematical expressions, or another suitable scalable format. Dependingon the implementation, map features can be defined in two dimensions(2D) only, in three dimensions (3D) as wireframes to which rastertextures are applied, in “two-and-a-half” dimensions (2.5D) as 2Dpolygons “extruded” into the third dimension, etc. In some cases, mapdata also can include raster images in a bitmap format, for example.Further, map data also can include text label and various forms ofmetadata such as links to remote resources.

The geographic database 150 can store the map data in the format of maptiles that generally correspond to a 2D organization of geospatial datainto a quadtree. Each tile at a given zoom level is divided into fourtiles at the next level up to the highest level of magnification.Similarly, 3D organization of geospatial data can be implemented usingoctrees, in which a cubic volume contains map geometry at a certain zoomlevel and is subdivided into eight cubic volumes at the next zoom level,with each of the eight cubic volumes typically containing a moredetailed map geometry. To map the surface of the Earth onto a plane for2D representation, Mercator or another suitable projection can be used.Although the examples below refer to map data organized into 2D maptiles, these techniques also can be extended to 3D map data organizedinto octrees.

In an example implementation, the geographic data server 112 referencesregions in the geographic database 150 using S2 cells, which correspondto subsections of a unit sphere generated by projecting the sphere ontoa cube. The level of an S2 cell indicates how much the sphere has beensubdivided. There are 6*4^(L) S2 cells at level L. The geographic dataserver 112 also can reference regions in the geographic database 150using Mercator tile coordinates, which are subsections of the unitsphere generated using a Mercator projection. The zoom of a tilecoordinate indicates how much the sphere has been subdivided, and thereare 4^(Z) Mercator tile coordinates at zoom level Z.

In addition to map data, the geographic database 150 can storepoint-of-interest (POI) data which can include geographic coordinates ofvarious places. For some of the places, the geographic database 150 canstore business data such as hours of operation, a description ofproducts and services offered, user reviews, etc. The POIs need notalways correspond to businesses and also can include landmarks (e.g.,monuments, fountains), prominent buildings and other structures,locations of events, etc. Further, the geographic database 150 can storespeech recognizer models that can be used to detect local queries, e.g.,names of local POIs or other locally common phrases.

The network coverage database 152 can store indications of how muchbandwidth is available at various locations, which can be referencedusing S2 cells, Mercator tile coordinates, or in any other suitablemanner. These indications can be specific to a carrier. An example of anetwork coverage table the network coverage database 152 can store isdiscussed below with reference to FIG. 10 .

The prediction rules database 154 can store rules for predicting likelydestinations for various locations, which can be approximated using S2cells for example. For example, when the client device is located on aninterstate highway, a prediction rule can predict that the client devicelikely will continue to travel on the interstate highway and not turn onrural roads. Another example prediction rule the location predictor 142can apply is that a user device located near a country border isunlikely to cross the border, especially when the client device is notnearby an official border crossing. Further, the database 154 can storeprediction rules based on observations for large sets of users. Forexample, a prediction rule can be based on the observation that userstend to move between certain locations and tend to not travel to otherlocations. Still further, prediction rules can be based both on thecurrent location and a certain number recent prior locations, so thatthe location predictor 142 can determine in which direction the userdevice is headed on a highway, for example. Thus, for the same location,the location predictor 142 can provide one set of predicted destinationswhen the user device is headed in one direction but a different set ofpredicted destinations when the user device is headed in the oppositedirection. Yet another prediction rule can be that the locationpredictor 142 omits regions to which there no roads, and whichaccordingly are not reachable by vehicles.

Still referring to FIG. 1 , the memory 126 of the client device 110 canstore instructions that implement various software applications such asa geographic application 160. The geographic application 160 cangenerate interactive digital maps, obtain navigation directions, providedata related to geolocated businesses in response to geographic queries,retrieve and display geographic commercial data such as coupons andoffers, etc. Depending on the implementation, the geographic application160 can operate as a standalone application or as a component of anotherapplication such as a web browser, for example.

The memory 126 of the client device 110 also can store map tiles 162that include geographic data for one or more geographic areas of offlinecoverage. Further, the memory 126 can store check-in bounds 164, or anindication of a geographic boundary delimiting a region inside ageographic area of offline coverage. Additionally or alternatively, thememory 126 can store check-in bounds that are based on time rather thangeography. Time-based check-in bounds can delimit time intervals duringwhich the client need not request additional geographic data. Asdiscussed in more detail below, the offline data manager 104 operatingin the client device 110 can request additional geographic data toexpand the geographic area of offline coverage upon reaching thecheck-in bounds 164.

In some implementations, the offline data controller 102 pre-computespredicted destinations and padding for various geographic locations andstores the pre-computed data in the database 156. Examples of predicteddestinations the database 156 can store are discussed below withreference to FIG. 8 , and an example padding table the database 156 canstore is discussed below with reference to FIG. 10 .

In operation, the client device 110 requests geographic data forpotential offline use from the geographic data server 112 under somespecific conditions, and the geographic data server 112 in responseprovides geographic data to the client device 110, selected so as reducethe probability the geographic application 160 is unable to display ageographic map via the user interface 122 due to insufficient networkcoverage. When the client device 110 operates in the offline mode, thegeographic application 160 can use the map tiles 162 and/or otheroffline geographic data received from the server 112 to generate offlinemaps, display information about businesses, provide navigationdirections, service geographic queries based on typed input or voiceinput (using one or more speech recognized models received from theserver 112), etc. Operation of the offline management system in variousscenarios is discussed in more detail next with reference to FIGS.2-16C.

Referring first to FIG. 2 , a diagram 200 illustrates example messagingbetween the client device 110 and the geographic data server 112 in thescenario where the client device 110 requests geographic data from thegeographic data server 112 for potential offline use. Unlike aninteraction during which the client device 110 requests map data for aspecific geographic area, such as when the user types in “Los Angeles,CA” or positions the map viewport over Los Angeles, CA, here the clientdevice 110 does not request geographic data for a specific geographicregion, and the geographic data server 112 determines which geographicthe client device is likely to need in the future.

To service such requests from the client device 110 and similar clientdevices more efficiently, the geographic data server 112 can pre-computepredicted destinations and padding information at block 202. Dependingon the implementation, the geographic data server 112 can execute block202 daily, weekly, or according to any other suitable schedule.

The client device 110 compares its current location to the check-inbounds at block 204. When the current location is outside the check-inbounds or within some threshold distance from the check-in bounds, theclient device 110 can transmit a request 206 to the geographic dataserver 112. When the check-in bounds are time-based, the client device110 can check whether a sufficient amount of time has passed since theclient device 110 last determined whether it should request additionalgeographic data for potential offline use. The client device 110 in someimplementations can check both the check-in bounds based on geographyand the check-in bounds based on time. In this manner, even when theclient device 110 is not outside the geographic check-in bounds, theclient device can request new geographic data if the age of thegeographic data currently stored in the local memory has exceeded athreshold number of hours, days, weeks, etc. Further, the geographicdata server 112 in some cases can provide the client device 110 withtime-based check-in bounds to simplify the check-in logic at the clientdevice 110, as it is generally easier to check a time interval than todetermine whether a point is outside a shape, especially a complexshape. If the client device 110 has not yet received the check-in boundsfrom the geographic data server 112, the client device 110 can set thecheck-in bounds to an initial value such as the minimal radius aroundthe current location of the client device, so that transmission of therequest 206 is triggered immediately.

The request 206 can include an indication of the current location of theclient device 110 in the form of Global Positioning Service (GPS)coordinates, for example. The request 206 can include an indication ofthe navigation route the client device 110 is following. Further, therequest 206 can include an indication of the network carrier, so thatthe geographic data server 112 can determine the amount of padding moreaccurately. This indication can include a mobile country code (MCC) anda mobile network code (MNC) tuple, or any other suitable information foridentifying the network carrier. Still further, the request 206 caninclude an indication of the desired format of the geographic data. Ingeneral, client devices can support different binary formats of theraster map tiles, vector map tiles, search results, routing information,etc. Moreover, the request 206 can include an indication of the regionsfor which the client device 110 already stores offline geographic datain the local memory (e.g., the memory 126 of FIG. 1 ).

The geographic data server 112 then can determine the extent of thegeographic area of offline coverage for the client device 110 in view ofthe parameters specified in the request 206, as well as the map tilesthat the geographic data server 112 must provide to the client device110 to cover this area (block 208). To this end, the geographic dataserver 112 can query the database 156 to determine the predicteddestinations and the padding. The geographic data server 112 alsodetermines the new check-in bounds.

The geographic data server 112 then initiates the process of providingthe geographic data and the check-in bounds to the client device 110 viaa sequence of responses 210. In one example implementation, the initialresponse from the geographic data server 112 includes a list of URLs orother references to portions of the geographic data to be downloadedalong with the check-in bounds. Because the geographic data server 112may need to provide a relatively large amount of information (e.g., XMB) in response to the request 206, the location of the client device110 can change significantly during the time it takes to transfer X MBover the communication network. The geographic data server 112accordingly determines the check-in bounds so that the client device 110requests the geographic data so as to finish the retrieval of theoffline geographic data before reaching any of the edges of thegeographic area of offline coverage. The client device 110 can continueto compare its location to the check-in bounds, during the process ofreceiving geographic data and after the process completes, asillustrated in block 212.

For further clarity, FIG. 3 illustrates an example method 300 forobtaining geographic data from a geographic data server for potentialoffline use, which can be implemented in a suitable client device. Forexample, the offline management system can implement the method 300 inthe client-side component, e.g., the offline data manager 104.

The method 300 begins at block 302, where the offline data manager 104stores geographic data for an area of offline coverage in the memory ofthe client device. The offline data manager 104 can store the geographicdata in the form of map tiles, for example.

At block 304, the offline data manager 104 can obtain an indication ofthe current check-in bounds for the area of geographic coverage. Thecheck-in bounds generally delimit a region smaller than, and whollycontained within, the area of geographic coverage. Referring to FIG.12A, for example, the check-in bounds 1202 delimit a region inside thelarger geographic area of offline coverage 1200.

The offline data manager 104 determines the current location of theclient device at block 306 and, at block 308, determines whether thecurrent location is within the check-in bounds. If the current locationis within the check-in bounds, as is the case in FIG. 12A, for example(where the current location of the client device is represented by alocation indicator 1204), the flow returns to block 306. The flow mayreturn to block 306 after a certain time interval, so that the offlinedata manager 104 periodically tests the current location against thecheck-in bounds. The time interval in some implementations can depend onthe current speed of the client device. Thus, the offline data manager104 tests the current location against the check-in bounds relativelyfrequently when the client device is moving fast, and tests the currentlocation against the check-in bounds relatively infrequently when theclient device is moving slowly. Otherwise, if the current location isoutside the check-in bounds or sufficiently close to the check-in bounds(see the location 1204-2 in FIG. 12B, for example), the flow proceeds toblock 310.

At block 310, the offline data manager 104 can retrieve additionalgeographic data and the new check-in bounds. To this end, the offlinedata manager 104 can transmit the message 206 as illustrated in FIG. 2 .The geographic data server accordingly can respond with a set ofresponses 210.

In some cases, the client device provides the offline geographic datavia the user interface at block 312. For example, the user can request adigital map of a location within the geographic area of offlinecoverage, submit a geographic query, etc. As another example, thegeographic application 160 can display the digital map to illustrate anavigation route. In general, block 312 can be executed at any timeduring execution of the method 300, or block 312 can be executed as apart of a separate process independent of the method 300.

Now referring to FIG. 4 , the offline data manager 104 also can auditthe offline geographic data to remove some of the data and thus preventthe geographic data from occupying an excessive portion of the localstorage of the client device 110, which may be implemented in thepersistent portion of the memory 126.

The method 400 begins at block 402, where a trigger event for auditing(or “garbage-collecting”) the offline geographic data is detected. Inone example implementation, the trigger event is retrieval of newgeographic data, e.g., transmittal of the request 206 or receipt of oneor more responses 210 (see FIG. 2 ). The trigger event alternatively canbe the expiration of a periodic timer. As yet another alternative, thetrigger event can be a command the offline data controller 102 issuesupon detecting a certain condition, such as a request to download acertain amount of geographic data. The offline data manager 104identifies the offline geographic data currently stored in the memory atblock 404. Then, at blocks 406-412, the offline geographic data canattempt to identify portions of the offline geographic data that can beremoved with a minimal risk of failing to provide the user with adigital map of a certain area upon request. Blocks 406-412 can beexecuted in any desired order.

The checks and tests the offline data manager 104 executes at blocks406-412 can include checking whether the data for a certain region isolder than X days, where X can be 30, 90, 365, or any suitable number(block 406); whether new versions of the data covering a certain regionhave been downloaded (408); whether the client deice is running low onmemory (block 410); whether there are more than N regions of offlinegeographic data stored in the memory of the client device (block 412).The offline data manager 104 can enforce the condition of block 412because the performance of the client device can degrade when the amountof offline geographic data in the memory is large. Additional examplesof checks and tests the offline data manager 104 can execute todetermine whether certain offline geographic data should be removed ishow recently the geographic application 160 used this data to display adigital map, provide search results, provide navigation, etc. Upondetermining how recently certain data was used, the offline data manager104 can first remove the less-recently used data. Further, in someimplementations, the offline data controller 102 can assist the offlinedata manager 104 in determining which offline geographic data should beremoved from the memory.

At block 414, the offline data manager 104 can remove the old orsuperseded data when one of the conditions of blocks 406 or 408 issatisfied, or remove the least recently used region when one of theconditions of blocks 410 or 412 is satisfied.

Alternatively, the offline data manager 104 can determine that the datarecognized as being old at block 406 should be used as backup in theevent the client device fails to download new data. Moreover, theoffline data manager 104 can request that the geographic data serverprovide a description of the difference between the map tilescorresponding to the old version and the map tiles corresponding to thenew version, instead of sending the map tiles corresponding to the newversion in their entirety, to reduce the amount of data transmitted viathe communication network. The offline data controller 102 can calculatea “diff” raster image, a diff vector-based map tile, or any othersuitable description of the difference between the versions alreadydownloaded to the client device 110 and available for download, for theregion or for a nearby area.

FIG. 5 illustrates an example method 500 for determining geographic dataand a boundary of a region of sufficient offline coverage. The offlinemanagement system can implement the method 500 in the server-sidecomponent, e.g., the offline data controller 102. The method 500 isconsidered next in connection with the diagrams in FIGS. 6-10 .

At block 502, the offline data controller 102 can receive a request foroffline geographic data from a client device. The offline datacontroller 102 for example can receive the message 206 including some orall of the parameters listed in FIG. 2 , as discussed above. Thus, theoffline data controller 102 receives an indication of the currentlocation of the client device, an indication of the network carrier,etc.

Next, at block 504, the offline data controller 102 can identifypredicted destinations for the client device. When the client deviceidentifies a navigation route in the request 206 (see FIG. 2 ), theoffline data controller 102 can determine that the entire area within Xkm of the navigation route corresponds to the likely destinations forthe client device, and accordingly the offline data controller 102 canselect map tiles covering this entire area at a certain zoom level. Thisexample scenario is further illustrated in FIGS. 16A-C. When the lengthof the navigation route exceeds a certain threshold value, the offlinedata controller 102 can select map data for the area within X km of onlythe first Y km of the navigation route.

When the client device does not specify a navigation route, the offlinedata controller 102 can rely on the location predictor 142 to determinelocations to which the client is likely to travel, based on theaggregate historical data for a set of users. The location predictor 142for efficiently can pre-compute this information and then retrieve thepre-computed predicted destinations from the database 156. As a morespecific example, the offline data controller 102 can determine to whatcells (rather than points or particular coordinates) the user device islikely to travel given the cell in which the user device currently islocated.

Referring to FIG. 6 , for example, a geographic area 600 can be dividedinto a grid 610 of S2 cells 612, 614, 616, etc. Each cell at aparticular level can cover a region of a certain fixed size. The examplecurrent location 610 of the client device is within cell 602.

As illustrated in FIG. 7 , the grid 610 of S2 need not correspond to maptiles into which the corresponding geographic data is divided. Forexample, a grid 700 of map tiles at a certain zoom level Z includestiles T_(1,1), T_(1,2), . . . T_(10,6), where each tile has anx-coordinate and y-coordinate. Thus, as illustrated in FIG. 7 , theexample cell 612 overlaps map tiles T_(2,3), T_(3,3), T_(2,4), andT_(3,4). The map tiles T_(2,3), T_(3,3), T_(2,4), and T_(3,4) cancorrespond to Mercator tile coordinates.

FIG. 8 illustrates an example predicted set 800 of map tiles which thelocation predictor 142 can generate for the example cell 612. Generallyspeaking, the location predictor 142 can determine where the clientdevice is likely to be in X hours given the current location of theclient device. The predicted set 800 is made up of tiles from the grid700 of FIG. 7 : in this example, the predicted set 800 includes tilesT_(1,5), T_(2,5), T_(3,5), T_(4,5), T_(2,4), T_(3,4), T_(2,3), T_(3,3),and T_(3,2). Each of these tiles covers a region to which the clientdevice located in the cell 612 is likely to travel. Thus, the predictedset 800 approximates the predicted geographic area for the cell 612. Toidentify the regions that make up the predicted destinations arearepresented by the predicted set 800, the location predictor 142 of FIG.1 can apply a set of prediction rules, as discussed above with referenceto the database 154. When the location predictor 142 is unable to applya suitable rule, the location predictor 142 can simply select map tileswithin a certain radius of the current location of the client device.

The predicted destinations and padding database 156 can store a mappingof S2 cells to sets of tile coordinates, e.g., cell 612-->{T_(1,5),T_(2,5), T_(3,5), T_(4,5), T_(2,4), T_(3,4), T_(2,3), T_(3,3), T_(3,2)}using tables, lists, trees, or any other suitable data structures. Insome implementations, the database 156 also stores scores for each maptile, where the scores indicate the likelihood of the map tile beinguseful. The location predictor 142 in some cases applies a score filterto the predicted destinations area 800 to reduce the number of tiles, asillustrated in FIGS. 14A and 14B, for example.

Referring back to FIG. 5 , at block 506 the offline data controller 102can identify padding regions for the tiles in the predicted destinationsarea. Generally speaking, the offline data controller 102 determinespadding regions for various locations to account for the displacement ofthe client device relative to the predicted geographic area while theclient device is downloading the corresponding geographic data. Forexample, if the predicted set 800 of map tiles takes up 100 MB, and theclient device can download on average 10 MB per minute while travelingat 60 miles per hour, the client device travels 10 miles before the 100MB download is complete. If the geographic area of offline coveragecoincides with the predicted destinations area covered by the predictedset 800 of map tiles, the client device is 10 miles closer to the edgeof the geographic area of offline coverage upon completing the download.At this new location, the client device may need to download additionalgeographic data, but if the quality of the available network coverage ispoor, the client device may be past the “point of no return,” or thepoint at which the client device needs to download more data than it hasthe bandwidth and the time to download before reaching the edge of thegeographic area of offline coverage.

Thus, the offline data controller 102 ensures that the client devicedownloads geographic data for an area large enough so that when theclient device requests additional geographic data, the client devicewill continue to have network coverage while downloading the additionalgeographic data. The offline data controller 102 determines the paddingregion for a location as a set of all points that can be reached fromthe location before X MB can be downloaded, where X MB is the size ofthe data covering the region that would be downloaded at the location.Once the offline data controller 102 augments the predicted destinationsarea with the padding regions for all locations in the predicteddestinations area, the resulting area of offline coverage has theproperty that all the points within the predicted destinations area arebefore the point of no return.

An example iterative technique for determining offline paddingrequirements for geographic cells is considered in detail with referenceto FIG. 11 . To implement this iterative technique, the offline datacontroller 102 can use a data structure 900 schematically illustrated inFIG. 9 , which stores indications of bandwidth for various S2 cells andvarious network carriers. Thus, for example, the data structure 900 canindicate that network carrier C1 provides approximately 5 Mbps at cell612, and that at cell 620, network carriers C1, C2, and C3 provideapproximately 10 Mbps, 5 Mbps, and 7 Mbps, respectively.

Using the method of FIG. 11 or another suitable technique, the offlinedata controller 102 can generate an example mapping 1000 that provides,for various map tiles and network carriers, lists of map tiles to beused as padding regions. Thus, according to the mapping 1000, thepadding region for tile T_(4,3) is tiles T_(2,2) and T_(3,2) whennetwork carrier C1 is used, and T_(2,2), T_(3,2), T_(2,3), T_(4,4) whennetwork carrier C2 is used. At block 506, the offline data controller102 can look up the padding regions for all the tiles included in thepredicted set 800 corresponding to the predicted destinations area.

At block 508, the offline data controller 102 excludes the offline dataalready available at the client device from the expanded region thatincludes the predicted destinations area determined at block 504 and thepadding regions determined at block 506. As discussed above, the clientdevice can report the already-available offline geographic data as apart of the request 206 (see FIG. 2 ). An example exclusion ofalready-available offline data is schematically illustrated in FIG. 12C.

In some implementations, the geographic data server 112 frequentlyupdates the data in the geographic database 150, but the changes arerelatively small. To preserve the bandwidth, the offline data controller102 can determine whether the version of certain geographic data issufficiently close to the version of the same geographic data availableat the client device, when the versions are not identical. When theversions are sufficiently close, the offline data controller 102excludes this data from download. The offline data controller 102 canapply one or several heuristics to compare versions such as for exampledetermining whether the map tile language, the legal country, and thestyling for application to the vector data in the corresponding maptiles match. Another example heuristic can include determining whetherthe routing versions (provided defined from map tile versions) areidentical. Yet another example heuristic can include determining whetherthe search language matches and the search versions (also definedseparately from map tile versions) differ from each other by no morethan X days (e.g., 14 days).

Next, at block 510, the offline data controller 102 determines thecheck-in bounds for the area of offline coverage. The offline datacontroller 102 first identifies the set of all data that has been orsoon will be downloaded the client, i.e., the data that corresponds tothe geographic area of offline coverage at the client device. Theoffline data controller 102 then erodes, or reduces along the perimeterthe geographic area of offline coverage so that the client device neverreaches the point of no return. Because the offline data controller 102has already determined the padding regions, the offline data controller102 can associate the check-in bounds with the boundary of the predicteddestinations area. Thus, the check-in bounds for a region contain allthe points for which the padding is contained in the region.

As one example, when the client device operates in a vehicle drivinginto a mountain range without coverage, the client device should startdownloading the entire area without coverage sufficiently early so thatthe client device completes the download before losing networkconnectivity. The offline data controller 102 accordingly provides thecheck-in bounds that trigger an early start of a download.

At block 512, the offline data controller 102 provides the geographicdata and the check-in bounds to the client device. Referring back toFIG. 2 , the geographic data server in which the offline data controller102 operates can send the response 210 to the client device.

In some implementations, the offline data controller 102 prioritizes thegeographic data being downloaded to a client device based on relevanceto advanced safety features, for example, and/or how essential differenttypes of geographic data are to navigation (e.g., gas and food can beprioritized over landmarks). In this manner, if the client devicereaches a point of no return, the client device still may have essentialgeographic data in the local memory.

Further, when the offline data controller 102 determines that a largeamount of geographic data for a large geographic region should bedownloaded to the client device, the offline data controller 102 cansplit the data into portions and prioritize the download based onproximity of the portions to the client device.

Now referring to FIG. 11 , an example method 1100 for computing offlinepadding regions for geographic cells can be implemented in the offlinedata controller 102. The offline data controller 102 can execute themethod 1100 periodically in a batch mode for a certain number of cells,prior to receiving requests from client devices. In otherimplementations or scenarios, however, the offline data controller 102executes the method 1100 in real time upon receiving a request from aclient device. The method 1100 generally is based on an iterativetechnique in which the steps of identifying locations reachable on acertain “budget” of data can impact on the budget, and some of the stepsof the method 1100 are repeated until the values representing the amountof data required to cover the region and the budget converge.

At block 1102, the offline data controller 102 sets the initial size ofthe budget 1100 to X. For example, when a client device at a certainlocation does not yet have any offline geographic data, the initial sizeof the budget 1100 can be the cumulative size of the predicted set 800of map tiles (see FIG. 8 ). The units of X can be for example megabytesor MB.

Next, at block 1104, the offline data controller 102 finds the set ofall points reachable with the budget of X. The offline data controller102 in general can apply any desired level of granularity for the set ofpoints. In an example implementation, each of the S2 cells is associatedwith a single location (e.g., the centroid of the cell or a point in theS2 cell accessible by a road). The offline data controller 102 can applyDijkstra's algorithm, a modification of the Dijkstra's algorithm, or anysuitable shortest-path algorithm to find a shortest path from thecurrent location of the client device to the various points.

As part of finding the set of points, the offline data controller 102 atblock 1106 can calculate the cost of traversing a cell. For a givencell, the offline data controller 102 can select the expected bandwidthavailable at the cell for the current network carrier of the clientdevice, e.g., 5 Mbps for cell 612, as illustrated in FIG. 9 . Asdiscussed above, the client device can specify the network carrier inthe request 206 (see FIG. 2 ). The offline data controller 102 then canmultiply the expected bandwidth by the linear size of the cell andfurther by the expected velocity at which the client device wouldtraverse the linear size of the cell. In an example configuration, theexpected velocity is set to a fixed maximum value for a vehicle such as100 mph or 160 kmh. In another example implementation, the offline datacontroller 102 determines the expected velocity based on historical datafor large sets of vehicles. Thus, for example, a certain S2 can cover adensely populated urban area in which vehicles historically travel atonly 40 mph or 60 kmh. The product of the bandwidth, size, and velocitycorresponds to the cost of traversing the cell.

It is noted that cells with poor network coverage and accordingly lowbandwidth have lower cost of traversing the cell. Thus, the same budgetselected at block 1102 covers a greater number of cells of poor networkcoverage. The offline data controller 102 accordingly can generatepadding regions that extend deep into areas of no or little coverage,such as mountain regions. However, to prevent the client device fromdownloading map tiles covering oceans and other areas inaccessible bycars, the offline data controller 102 can restrict the search at block1104 to only those S2 cells that contain roads. As another example,referring back to FIG. 8 , the predicted set 800 for cell 612 extendsfarther into the upper left corner than directly to the right of thecell 612 because the network coverage is worse at the locations a clientdevice would traverse on the way to a location in the upper left corner.

In some implementations, the offline data controller 102 detects thatthe network padding expands too much for some areas (e.g., grows toencompass an entire continent), and the offline data controller 102limits the expansion based on a maximum number of S2 cells, on a maximumdistance from the location of the cell, or based on any other suitableprinciple.

Next, at block 1110, the size of the area generated at block 1104 iscomputed and set as the new budget. In particular, the offline datacontroller 102 can compute the total size of all the cells reachablefrom the given cell in accordance with the shortest path algorithm andfor the budget used in the previous instance of executing block 1104.

If the size calculated at block 1110 is not larger than the previouslyused budget, the offline data controller 102 can determine at block 1112than converge has been achieved and proceed to block 1114. Otherwise, ifthe size is larger than the previously used budget, the size is used asthe new budget, and the flow returns to block 1104. The offline datacontroller 102 can always achieve convergence as any geographic area isfinite, but in most cases convergence is achieved quickly when the setsof cells at block 1104 have robust network coverage.

At block 1114, the offline data controller 102 adds a new entry to themapping 1000 illustrated in FIG. 10 . The offline data controller 102 inthe example of FIG. 10 maintains these entries in the map tile formatrather than the S2 cell format, and thus an entry in the table 1000 fortile T_(4,3) can specify a padding region of {T_(2,2), T_(3,2), T_(2,3),T_(4,4)} when network carrier C2 is used. More generally, the offlinedata controller 102 can define and index padding regions in any suitablegeographic format.

As one alternative to executing block 1114, when servicing requests fromclient devices in real time, the offline data controller 102 uses theresult of executing blocks 102-112 to directly apply the padding regionto the previously calculated predicted geographic area to determine theoverall set of map tiles to be provided to the client device in responseto the request 206.

For further clarity, FIGS. 12A-16C next illustrate several examplescenarios according to which the offline management system of thisdisclosure can operate.

First, FIGS. 12A-C schematically illustrate, from the perspective of aclient device such as the device 110 of FIG. 1 , an example scenario inwhich the client device reaches the check-in bounds and requestsadditional geographic data. In the initial state of FIG. 12A, the clientdevice has an area of offline coverage 1200. The check-in bounds 1202delimit a region within the area of offline coverage 1200, and thecurrent location 1204 of the client device is within the check-inbounds.

As illustrated in FIG. 12B, the client device then moves to a newlocation 1204-01 and reaches the check-in bounds 1202. The client deviceaccordingly sends a message similar to the message 206 of FIG. 2 to thegeographic data server, and in response the geographic data serverprovides additional geographic data illustrated as the shaded area 1210and provides the updated check-in bounds 1202-01.

As a result, the area of offline geographic coverage now encompasses theregions 1200 and 1210 (FIG. 12C). The client device can continue to moveto the new location 1204-02, where the client device is within theupdated check-in bounds 1202-01 and accordingly does not need to requestadditional geographic data at the location 1204-02.

Next, FIGS. 13A-E schematically illustrate, from the perspective of aserver such as the geographic data server 112 of FIG. 1 , an examplescenario in which the server determines what geographic data should beprovided to a client device for potential offline use.

FIG. 13A illustrates an example area of offline coverage 1300, which theserver erodes down to the check-in bounds 1302 based on connectivity, asdiscussed above. In FIG. 13B, the server determines a predicteddestinations area 1306 for a location 1310. The server then can pad thepredicted destinations area 1306 based on network connectivity togenerate an expanded region 1320 (FIG. 13C). Then, the server can removethe existing region geometry from the expanded region 1320 to identifyan area 1330 (shaded in FIG. 13D) for downloading to the client device.Finally, the server can erode the union of the geographic areas 1300 and1320 to generate new check-in bounds 1340 (see FIG. 13E).

FIGS. 14A and 14B schematically illustrate an example scenario in whichthe server of FIG. 1 generates a Mercator covering for a set of S2 cellscorresponding to predicted destinations of the client device. Inparticular, the server can generate a predicted destinations area 1400for an S2 cell 1402 (FIG. 14A), filter the predicted destinations area1400 based on scores to generate a modified predicted destinations area1410 and generate a Mercator covering 1420 for the modified predicteddestinations area 1410 (FIG. 14B).

FIGS. 15A-F schematically illustrate an example determination of networkpadding for a predicted geographic area.

The server can compute the size of the predicted destinations area orregion for every S2 cell. FIG. 15A illustrates an example predicteddestinations area 1510 for a cell 1500. The server then can expand theregion around the cell 1500 to cover the cells where X MB can bedownloaded. The resulting region 1520 is illustrated in FIG. 15B. Asdiscussed above, the server can apply a shortest-path search to identifycells reachable for the budget X.

The server then can compute a Mercator covering 1522 for the region 1520(FIG. 15C). Referring to FIG. 15D, the server then can union the networkpadding 1530-1, 1530-2, 1530-3, . . . 1530-N and the geographic region1520 to generate a new area 1540 of new size X′. The regions 1540 and1520 thus have different sizes, as illustrated more clearly in FIG. 15E.Accordingly, the new size X′ is used in the new iteration of determiningthe network padding, and the process continues until the sizes 1540,1550, 1560, etc. converge (FIG. 15F)

As illustrated next in FIGS. 16A-C, the process of identifying paddingregions for a navigation route is generally similar to the processdiscussed above, except that the padding applies to the locations aroundthe route rather than predicted destinations. In FIG. 16A, for example,the server can identify a set of cells 1610, each of which is within thecertain distance of the route 1600. FIG. 16B then illustrates a union ofthe cells 1610 with the respective padding regions 1620-1, 1620-2,1620-3, . . . 1620-N.

The result of this union is illustrated in FIG. 16C as the area ofoffline coverage 1650. The region covered by the cells 1610 defines thecheck-in bounds for the area of offline coverage 1650.

ADDITIONAL CONSIDERATIONS

The following additional considerations apply to the foregoingdiscussion. Throughout this specification, plural instances mayimplement components, operations, or structures described as a singleinstance. Although individual operations of one or more methods areillustrated and described as separate operations, one or more of theindividual operations may be performed concurrently, and nothingrequires that the operations be performed in the order illustrated.Structures and functionality presented as separate components in exampleconfigurations may be implemented as a combined structure or component.Similarly, structures and functionality presented as a single componentmay be implemented as separate components. These and other variations,modifications, additions, and improvements fall within the scope of thesubject matter of the present disclosure.

Additionally, certain embodiments are described herein as includinglogic or a number of components and modules. Modules may constituteeither software modules (e.g., code stored on a machine-readable medium)or hardware modules. A hardware module is tangible unit capable ofperforming certain operations and may be configured or arranged in acertain manner. In example embodiments, one or more computer systems(e.g., a standalone, client or server computer system) or one or morehardware modules of a computer system (e.g., a processor or a group ofprocessors) may be configured by software (e.g., an application orapplication portion) as a hardware module that operates to performcertain operations as described herein.

In various embodiments, a hardware module may comprise dedicatedcircuitry or logic that is permanently configured (e.g., as aspecial-purpose processor, such as a field programmable gate array(FPGA) or an application-specific integrated circuit (ASIC)) to performcertain operations. A hardware module may also comprise programmablelogic or circuitry (e.g., as encompassed within a general-purposeprocessor or other programmable processor) that is temporarilyconfigured by software to perform certain operations. It will beappreciated that the decision to implement a hardware module indedicated and permanently configured circuitry, or in temporarilyconfigured circuitry (e.g., configured by software) may be driven bycost and time considerations.

Accordingly, the term hardware should be understood to encompass atangible entity, be that an entity that is physically constructed,permanently configured (e.g., hardwired), or temporarily configured(e.g., programmed) to operate in a certain manner or to perform certainoperations described herein. As used herein “hardware-implementedmodule” refers to a hardware module. Considering embodiments in whichhardware modules are temporarily configured (e.g., programmed), each ofthe hardware modules need not be configured or instantiated at any oneinstance in time. For example, where the hardware modules comprise ageneral-purpose processor configured using software, the general-purposeprocessor may be configured as respective different hardware modules atdifferent times. Software may accordingly configured on a processor, forexample, to constitute a particular hardware module at one instance oftime and to constitute a different hardware module at a differentinstance of time.

Hardware modules can provide information to, and receive informationfrom, other hardware. Accordingly, the described hardware modules may beregarded as being communicatively coupled. Where multiple of suchhardware modules exist contemporaneously, communications may be achievedthrough signal transmission (e.g., over appropriate circuits and buses)that connect the hardware modules. In embodiments in which multiplehardware modules are configured or instantiated at different times,communications between such hardware modules may be achieved, forexample, through the storage and retrieval of information in memorystructures to which the multiple hardware modules have access. Forexample, one hardware module may perform an operation and store theoutput of that operation in a memory device to which it iscommunicatively coupled. A further hardware module may then, at a latertime, access the memory device to retrieve and process the storedoutput. Hardware modules may also initiate communications with input oroutput devices, and can operate on a resource (e.g., a collection ofinformation).

The methods discussed above may include one or more function blocks,modules, individual functions or routines in the form of tangiblecomputer-executable instructions that are stored in a non-transitorycomputer-readable storage medium and executed using a processor of acomputing device (e.g., a server, a personal computer, a smart phone, atablet computer, a smart watch, a mobile computing device, or otherpersonal computing device, as described herein). The methods discussedabove may be included as part of any backend server (e.g., a map dataserver, a navigation server, or any other type of server computingdevice, as described herein), portable device modules of the exampleenvironment, for example, or as part of a module that is external tosuch an environment. Though the figures may be described with referenceto the other figures for ease of explanation, the methods discussedabove can be utilized with other objects and user interfaces.Furthermore, although the explanation above describes steps of themethods discussed above being performed by specific devices, this isdone for illustration purposes only.

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example embodiments, compriseprocessor-implemented modules.

Similarly, the methods or routines described herein may be at leastpartially processor-implemented. For example, at least some of theoperations of a method may be performed by one or more processors orprocessor-implemented hardware modules. The performance of certain ofthe operations may be distributed among the one or more processors, notonly residing within a single machine, but deployed across a number ofmachines. In some example embodiments, the processor or processors maybe located in a single location (e.g., within a home environment, anoffice environment or as a server farm), while in other embodiments theprocessors may be distributed across a number of locations.

The one or more processors may also operate to support performance ofthe relevant operations in a “cloud computing” environment or as anSaaS. For example, as indicated above, at least some of the operationsmay be performed by a group of computers (as examples of machinesincluding processors), these operations being accessible via a network(e.g., the Internet) and via one or more appropriate interfaces (e.g.,APIs).

Still further, the figures depict some embodiments of the exampleenvironment for purposes of illustration only. One skilled in the artwill readily recognize from the following discussion that alternativeembodiments of the structures and methods illustrated herein may beemployed without departing from the principles described herein.

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs forgenerating offline geographic data through the disclosed principlesherein. Thus, while particular embodiments and applications have beenillustrated and described, it is to be understood that the disclosedembodiments are not limited to the precise construction and componentsdisclosed herein. Various modifications, changes and variations, whichwill be apparent to those skilled in the art, may be made in thearrangement, operation and details of the method and apparatus disclosedherein without departing from the spirit and scope defined in theappended claims.

What is claimed is:
 1. A method for providing geographic data to clientdevices for offline use, the method comprising: receiving, by one ormore processors from a client device via a communication network, anindication of a current location of the client device; identifying, bythe one or more processors, geographic data to be provided to the clientdevice to define an area of offline coverage, including determiningboundaries of the area of offline coverage based on an amount ofgeographic data the client device is expected to receive prior toreaching certain points within the area of offline coverage; andproviding the geographic data to the client device.
 2. The method ofclaim 1, wherein determining the boundaries of the area of offlinecoverage includes: determining, within the area of offline coverage, aregion smaller than the area of offline coverage and contained withinthe area of offline coverage, such that the client device is expected toreceive the geographic data for the region of offline coverage by thetime the client reaches any point in the region.
 3. The method of claim2, further comprising providing an indication of a boundary of theregion to the client device so that the client device requestsadditional geographic data upon reaching the indicated boundary.
 4. Themethod of claim 1, further comprising receiving, from the client devicevia the communication network, an indication of a geographic area forwhich the client device currently stores previously received geographicdata.
 5. The method of claim 4, further comprising: determining whethera version of the previously received geographic data is suitable for usefor the region of offline coverage, and not providing the previouslyreceived geographic data to the client device when the version of thepreviously received geographic data is suitable for use for the regionof offline coverage.
 6. The method of claim 1, further comprisingdetermining network bandwidth for cells within the region based onhistorical data.
 7. The method of claim 1, further comprising:receiving, from the client device, a request for additional geographicdata specifying a new current location of the client device and acurrent area of offline coverage; and providing additional geographicdata in response to the request.
 8. The method of claim 7, wherein therequest further specifies a network carrier of the client device at thenew current location.
 9. The method of claim 7, wherein the requestfurther specifies a navigation route which the client device isfollowing.
 10. The method of claim 7, wherein the request furtherspecifies a current speed and/or an expected future speed of travel ofthe client device.
 11. A server device comprising: one or moreprocessors; and a non-transitory computer-readable medium storingthereon instructions that, when executed by the one or more processors,cause the server device to: receive, from a client device via acommunication network, an indication of a current location of the clientdevice, identify geographic data to be provided to the client device todefine an area of offline coverage, including determine boundaries ofthe area of offline coverage based on an amount of geographic data theclient device is expected to receive prior to reaching certain pointswithin the area of offline coverage, and provide the geographic data tothe client device.
 12. The server device of claim 11, wherein todetermine the boundaries of the area of offline coverage, theinstructions further cause the server device to: determine, within thearea of offline coverage, a region smaller than the area of offlinecoverage and contained within the area of offline coverage, such thatthe client device is expected to receive the geographic data for theregion of offline coverage by the time the client reaches any point inthe region.
 13. The server device of claim 12, wherein the instructionsfurther cause the server device to: provide an indication of a boundaryof the region to the client device so that the client device requestsadditional geographic data upon reaching the indicated boundary.
 14. Theserver device of claim 11, wherein the instructions further cause theserver device to: receive, from the client device via the communicationnetwork, an indication of a geographic area for which the client devicecurrently stores previously received geographic data.
 15. The serverdevice of claim 14, wherein the instructions further cause the serverdevice to: determine whether a version of the previously receivedgeographic data is suitable for use for the region of offline coverage,and not provide the previously received geographic data to the clientdevice when the version of the previously received geographic data issuitable for use for the region of offline coverage.
 16. The serverdevice of claim 11, wherein the instructions further cause servicedevice to: determine network bandwidth for cells within the region basedon historical data.
 17. The server device of claim 11, wherein theinstructions further cause service device to: receive, from the clientdevice, a request for additional geographic data specifying a newcurrent location of the client device and a current area of offlinecoverage; and provide additional geographic data in response to therequest.
 18. The server device of claim 17, wherein the request furtherspecifies a network carrier of the client device at the new currentlocation.
 19. The server device of claim 17, wherein the request furtherspecifies a navigation route which the client device is following. 20.The server device of claim 17, wherein the request further specifies acurrent speed and/or an expected future speed of travel of the clientdevice.